home *** CD-ROM | disk | FTP | other *** search
/ Aminet 4 / Aminet 4 - November 1994.iso / aminet / dev / amos / amosl0794.lzh / AMOSLIST / 000116_amos-request@svcs1.digex.net_Tue Jul 26 02:46:18 1994.msg < prev    next >
Internet Message Format  |  1994-08-01  |  4KB
  1. Received: from hela.INS.CWRU.Edu by nfs1.digex.net with SMTP id AA05015
  2.   (5.67b8/IDA-1.5 for <mcox@access.digex.net>); Tue, 26 Jul 1994 02:46:16 -0400
  3. Received: from svcs1.digex.net (svcs1.digex.net [164.109.10.23]) by hela.INS.CWRU.Edu with SMTP (8.6.8.1+cwru/CWRU-2.1-freenet-gw)
  4.     id CAA24419; Tue, 26 Jul 1994 02:46:08 -0400 (from amos-request@svcs1.digex.net)
  5. Received: by svcs1.digex.net id AA28275
  6.   (5.67b8/IDA-1.5 for amos-out); Tue, 26 Jul 1994 00:22:09 -0400
  7. Received: from nfs1.digex.net by svcs1.digex.net with SMTP id AA28269
  8.   (5.67b8/IDA-1.5 for <amos@svcs1.digex.net>); Tue, 26 Jul 1994 00:22:06 -0400
  9. Received: from inca.gate.net by nfs1.digex.net with SMTP id AA28775
  10.   (5.67b8/IDA-1.5 for <amos-list@access.digex.net>); Tue, 26 Jul 1994 00:22:02 -0400
  11. Received: (from rscott@localhost) by inca.gate.net (8.6.9/8.6.9) id AAA203423; Tue, 26 Jul 1994 00:21:26 -0400
  12. Date: Tue, 26 Jul 1994 00:14:29 -0400 (EDT)
  13. From: Ryan Scott <rscott@gate.net>
  14. Subject: Re: Proposal
  15. To: Dominic Ramsey <dom@dynamo.demon.co.uk>
  16. Cc: amos-list@access.digex.net
  17. In-Reply-To: <9407251239.AA0003n@dynamo.demon.co.uk>
  18. Message-Id: <Pine.3.87.9407260028.A9884-0100000@inca.gate.net>
  19. Mime-Version: 1.0
  20. Content-Type: TEXT/PLAIN; charset=US-ASCII
  21. Status: RO
  22.  
  23.  
  24.  
  25. On Mon, 25 Jul 1994, Dominic Ramsey wrote:
  26.  
  27. > 
  28. > >   Given the likelihood (or is it certain now?) of the AMOS source code
  29. > > eventually going into the public domain, I think a team of programmers
  30. > > should be created which would work on improving AMOS, fixing the bugs,
  31. > > etc.  The team would discuss problems and send code through E-mail, and
  32. > > release updates occasionally.  This way work on AMOS could be
  33. > > coordinated and accomplished quickly, and there would be a single
  34. > > official version, rather than people going and making their own changes
  35. > 
  36. > If you wanted it to be `official', you'd have to talk to Europress first.
  37. > If they release it as PD, then ANYONE will be able to do whatever they
  38. > want with it.
  39.  
  40. official didn't mean 'Official Europress Seal of Approval'... Just to 
  41. group the most interested parties to come out with a well thought out plan..
  42.  
  43. > 
  44. > > to the code and having lots of different versions (which would most
  45. > > likely be incompatible with each other).
  46. > > 
  47. > >   If you would be interested in joining such a team, let me know.  You
  48. > > will need experience in assembler, since that's what AMOS is written in.
  49. > 
  50. > I don't see any reason why assembler experience should be needed. There are
  51. > a lot of very experienced AMOS programmers who know nothing about assembler.
  52. > 
  53.  
  54. True, but what code are they going to write for AMOS?  The development 
  55. list should only have folks who are integral to development, with input 
  56. from the regular amos list, which most in the project would already be on.
  57.  
  58. > > The AMOS code itself probably won't be out for a while, but the team
  59. > > could still bounce around ideas, compile a bug list, etc., and be able
  60. > > to start working immediately when the code is finally released.
  61. > > 
  62. > >   --Andy Church
  63. > 
  64. > Something I'd like to see would be a change to the extensions system, so
  65. > any number of extensions could be loaded at once, and not have to have their
  66. > own extension number. I think this will be a big problem if/when the source
  67. > code becomes available, with everyone producing their own extensions.
  68. > 
  69.  
  70. Yeah, I agree 100%.  And Manuel tells me that with AMOS Pro, 2 registers 
  71. get saved & restored every time a command is called in an extension.  
  72. This wastes lots of time...
  73.  
  74. He's discovered many many new areas that need fixing up.  He's gone 
  75. through more areas of the source code - believes he can speed up sprites 
  76. at least 2-3 times, bobs at least the same, working on copper list 
  77. routines, copperwrap 8 way scroller, aga graphics, and lots of other 
  78. goodies at the moment.  Sped up Screen command which can make a big 
  79. difference depending on the program.  300-25% or thereabouts...
  80.  
  81. AMOS still has a VAST amount of power that we're just starting to chip 
  82. away at.  It can go many many times faster than it currently does.  Thats 
  83. pretty much the aim of the TURBO project - *speed*
  84.  
  85.  
  86.  
  87.